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(57) ABSTRACT 

A monitor located between a Web browser and a server upon 
which a server application is running. The monitor is useful 
for recording a set of URLs (sometimes referred to as a 
"request list") that issue from the Web browser during a 
sample interactive session between the user of the client 
machine and the server application. The URL request list 
trace or session "workload" may then be used to benchmark 
the server application by supplying the information as an 
input to a set of HTTP submitter routines. Each HTTP 
submitter routine simulates a particular user of a client 
machine connected to the server application. Each routine 
then "replays" the interactive session recorded by the moni- 
tor so that the overall performance of the server application 
against "multiple" simulated users may be evaluated. 

29 Claims, 3 Drawing Sheets 
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METHOD OF RECORDING AND server application, such as an e-business application, to 

MEASURING E-BUSINESS SESSIONS ON thereby generate "workload" information that may then be 

THE WORLD WIDE WEB f° r * ater playback to benchmark the server application. 

BRIEF SUMMARY OF THE INVENTION 
The present invention provides a monitor tool that pref- 

1. Technical Field erably sits between a Web browser and a server upon which 
The present invention relates generally to communica- a appUcaUon is mnning. The monitor tool is useful for 

tions within a client^erver computer network and, in re ^ rdmg a * l of f URL * (^etmies referred to as a "request 

particular, to a method of recording and measuring infer- 10 ^ ^ ^ f Tn T brows ?^ durm g ( a sam P le 

r A . / A . , . & . . z mteractive session between the user of the client machine 

maUon about a particular communicate session between a and ^ ^ URL , ^ [race or 

chent application and a server apphcaUon. may ^ be ^ £ benchmark thc 

2. Description of the Related Art server application by supplying the information as an input 
Doing business in an electronic manner is highly advan- to a set of HTTP submitter routines. Each HTTP submitter 

tageous. An electronic business or so-called "e-business** is 15 routine simulates a particular user of a client machine 

one that uses certain tools to connect its critical business connected to the server application. Each routine then 

systems directly to employees, customers, vendors and other "replays" the interactive session recorded by the monitor so 

important constituencies. An "intranet" is an e-business that me overaU perfonnance of the server apphcation against 

application deployed within a business. An "extranet" is an "multiple*' simulated users may be evaluated, 

e-business application deployed within the larger commu- 20 The monitor tool is provisioned such that, from the 

nity of a business, including its suppliers, vendors and ^"^J? P«spective. tool appears to be the server 

contractors. Connecting either one to the Internet's World ltsc ^ Mcwsc, from the server s perspective, the tool 

nr . Hi « | * p •* * • -li a. appears to be the browser. Moreover, communications 

Wide Web makes the information it contains accessible from . y y . , . ... 

. • 4-11 between the browser and the monitor are earned out in an 

anywhere using conventional browser software. . , . m j. * 

J to zs unencrypted manner, although the monitor provides what- 

A goal of e-business is to move online all processes that cver sa^tc connection (e.g., a secure sockets layer ("SSL") 

require a dynamic and interactive flow of information. These connection) that is expected or may be required with respect 

include, without limitation, service and support, managing to the communications to and from the server. The monitor 

supply chains, buying and selling, and the like. Examples of further includes a link substitution algorithm that prevents 

an e-business application include Internet banking or Inter- the browser from escaping from the connection to the 

net retail sales. 30 monitor. In addition, the monitor tool may also be used to 

Because an e-business application running on a Web measure response times associated with the interactive ses- 

server may have to support a large number of interactions in S10n - 

a given time period, measuring and tuning the performance The foregoing has outlined some of the more pertinent 

of the application is an important goal. Similarly, because „ objects and features of the present invention. These objects 

reliability and functional correctness of the e-business appli- 35 should be ^"^tru/d to be merely illustrative i of some of the 

cation are paramount, functional and system testing of the f° re P™™ 1 a * d a PP^ ons of thc invention. 

4 * , . * **t j f * Many other beneficial results can be attained by applying the 

application are also important elements of the development j /j- j-n- * j-*.- »t_ 

rr A1 . c . Ji . c 4t _ , . r disclosed mvenUon ui a different manner or modifying the 

process. Also, if an individual user of the e-business apph- as ^ ^ described . Accordingly, other objects 

cation encounters poor response time it may be important ^ and a foller understanding of ^ invention may be had by 

from a customer service viewpoint to be able to quantify and referring t0 me following Detailed Description of the Pre- 

measure the exact nature of the user's performance difficulty ferred Embodiment 
in order to resolve the problem. Such measurements should 

concentrate on the delay of the server as it interacts with the BRIEF DESCRIPTION OF THE DRAWINGS 

user as opposed to measuring performance characteristics of 45 For a more complete understanding of the present inven- 

the client machine (e.g., how long it takes the browser to tion and the advantages thereof, reference should be made to 

render the servers response on the client machine). the following Detailed Description taken in connection with 

An important part of performance measurement and sys- the accompanying drawings in which: 

tern testing of an e-business application is the problem of FIG. 1 is a representative client-server computer system 

capturing a test workload. A test workload is a set of URL 50 of the Prior Art; 

requests that take place between a client application and a FIG. 2 is an illustrative network environment in which the 

e-business application during a simulated or "sample" inter- present invention is implemented; 

active session involving the application. A test workload, FIG. 3 is a flowchart illustrating a preferred method of 

theoretically, could be replayed to the server for perfor- using the inventive monitor in a performance or functional 

mance measurement or functional testing purposes. The 55 testing environment; 

prior art, however, does not provide any adequate means or FIG. 4 is a flowchart illustrating a preferred method of 

method of compiling such workload information. A possible ^ inventive monitor in an end user measurement 

solution is a manual "monitoring*' technique, wherein one environment; 

could just watch the URLs that the browser submits and FIG. 5 is a flowchart illustrating a preferred routine for 

copy these URLs down by hand m order to create a list of w mitiati and mnaBtidBg a Web browser to me monitor . and 

requests to the applicauon (i.e. a request list"). For most mr* < - a n. „ 1 „ 

l . t ."\ , v l*t«t 1 FIG. 6 is a flowchart illustrating a preferred operating 

e-business applications, however, the URLs are complex ^ llt - , f . - tnr or & 

j l _. * j j. \ «iiot ». „ n . routine for the monitor. 

and hard to read due to "URL encoding^. Copying the 

requests down by hand is thus extremely error prone for all DETAILED DESCRIPTION OF THE 

but the simplest of e-business applications. 65 PREFERRED EMBODIMENT 

Thus, there remains a need to provide a technique to A representative client-server network system known in 

monitor and record information about specific requests to a the Prior Art is illustrated in FIG. 1. A client machine 10 is 
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connected to a Web server platform 12 via network 14. For generated from tbe client machine and passed to the 

illustrative purposes, network 14 is the Internet, an Intranet e-business application or to other applications associated 

or other known network connection. Webserver platform 12 therewith. Thus, for example, consider a typical Internet 

is one of a plurality of servers which are accessible by banking transaction. In a given session, a user may logon, 

clients, one of which is illustrated by machine 10. A repre- 5 ask for an account balance, write an electronic check, 

sentative client machine includes a processor 11, operating deposit funds, and then logoff. One or more of these tasks 

system 13, graphical user interface 15, and a Web browser ma y require a connection from the client to the e-business 

16. A Web browser is a known software tool used to access server application (or to some third party application asso- 

the servers of the network. The Web server platform sup- ***** * e 'ewith). Moreover, a particular URL may be quite 

ports files (collectively referred to as a "Web" site) in the to °°™P ? x ® Vtn r be 

form of hypertext documents and objects. In the Internet ^ * C ^ UCSt > t0 ™ tcr V * nous ficlds «f ^formation 

paradigm/a network path to a server is identified by a (^caUy through a CGI scripting process or the like), 
so-called Uniform Resource Locator (URL). According to the invention, the URL request list trace or 

* «/ 1_ o i *r session "workload" for the particular interactive session is 

•n£ , *5S , P ?«T h C 2 mP I 1S !i aD ,s rccorded in » ^ 44. The information in the file 44 may then 

IBM RISC System/6000 computer 18 (a reduced tnstruction 15 be ^ to benchmlrk the ^ applicati ; n by 

set of soiled RISC-based workstation) running the AIX® s ^ ^ MoTmhtioa ^ „ ■ t l0 a ™ of HTTP 
(Advanced Interactive Executive Version 4.1 and above) routines 46a _„ ^ HT TP submitter routine 46 

Operating System 20 and a Web server program 22. such as „■ f _ , c ,. . . , . 

VT \ * \ 0 w • - « t_ ■ simulates a particular user of a cbent machine connected to 

Netscape Enterprise Server Version 2.0, that supports inter- # . _ ^ ,. . , . - # . 

- r . r — ... ' , , rr t* , on the server application. In a separate process, each of the set 

face extensions. The platform 12 also includes a graphical 20 o tjt-™ « ♦,• *u „ • » 

r , « . . . °f HTTP submitter routines then replays the interactive 

user interface (GUI) 24 for management and administration. ™„;«„ „ „a~a u„ *u~ ~ ^ n f- 

m. nr t. <o i • i j a . ™ session recorded by the monitor so that the overall perfor- 

The Web server 18 also includes an Application Program- m „ „ t tU r ** • * n - , 

t r /AnT v.. , . , " . & , , mance of the server application against multiple users may 

ming Interface (API) 23 that provides extensions to enable be evakat^j 

application developers to extend and/or customize the core „ " . , c . . . ... 

i . r.u u r^- i ic Because the conduct of the e-business application may 

functionality thereof through software programs commonly 2 * . . , c . 4 . r . , ^ 

referred to as w plue-ins " require the exchange of private information (e.g., credit card 

• «»/,-. . . numbers or other personal data), the connection between the 

Arepresentative Web chent is a personal computer that is browser md ^ may ^ co nductcd ^ the « https » 

x86-, PowerPC®- or RISC-based, that includes an operating (or layer) protoco i. As is known, the Secure 

system such as IBM® OS/2® or Microsoft Windows 95 and Socket u (SSL) protocol 3 ^ defined by a ^ 

that includes a browser, such as Netscape Navigator 3.0 (or Internet standard mal ^ available Net scape Commu- 

higher), having a Java Virtual Machine (JVM) and support nic ations Corporation. That standard is incorporated herein 

for application plug-ins and helper applications. by refererlce . A characteristic of SSL is that the connection 

As is well-known, the Web server accepts a client request between the browser and the server is encrypted and third 
and returns a response. The communication between the 3S parties are theoretically unable to decipher the content of the 
browser and the server is conducted using the HTTP pro- exchange between the browser and server, 
tocol. According to the present invention, it is assumed that The requests issued by the browser 32 to the monitor 40 
the Web server supports an e-business application under are unencrypted over connector 42 (which may be an 
development, testing or (perhaps) in use. The present inven- interprocess communication path (IPC). Nevertheless, the 
tion provides a mechanism to capture and replay a session ^ connection 43 between the browser and the Web server may 
between a Web browser and a Web server supporting a given still be an https (secure socket or other such secure) con- 
server application. For purposes of discussion, this session is nection because the monitor 40 establishes the secure socket 
associated with a given e-business application provided connection to the server 36 (while the connection between 
from a set of one or more servers in the computer network. me browser and the server is an unencrypted (e.g., http) 
One of ordinary skill, however, will recognize that the 45 connection). When the monitor receives the request from the 
principles of the invention are not limited to just monitoring browser, it preferably uses the SSL (https) protocol to 
session information during an e-business transaction. forward the request to the server if that is the protocol the 

FIG. 2 illustrates a system in which the present invention server uses. Thus, strictly speaking, the monitor does not 

is implemented. It includes a client machine 30 having a bypass SSL; it merely adds SSL to the connection. 
Web browser 32, which is connectable via network 34 to a 50 As illustrated in FIG. 2, according to the invention, when 

set of one or more servers 36a-36n at least one of which the monitor is in use, all requests that would normally be 

supports a given e-business application 38. Network 34 may sent to the server 36 are sent to the monitor 40 instead. The 

be an intranet, an extranet, the Internet, or any known or monitor 40 then forwards the requests to the actual server 

later-developed computer network. The objects of the and receives the responses from the server 36. Responses 

present invention are provided by a monitor 40, which is 55 from the server are then returned from the monitor 40 to the 

preferably supported and run on the client machine as browser 32. In effect, the monitor 40 acts as an HTTP 

illustrated. The monitor 40 may be supported and run on request/response forwarder that masquerades as the actual 

another machine, of course, including a machine connected server (as far as the browser is concerned) and the actual 

to the chent. Regardless of where it is supported, the monitor browser (as far as the server is concerned). To achieve the 

is designed to sit between the browser and the server that 60 masquerade, the monitor 40 translates the HTTP requests 

implements the e-business application. received from the browser 32 before sending these requests 

The primary function of the monitor 40 is to record a set to the server, and it translates the HTTP responses and 

of URLs (sometimes referred to as a "request list") that issue HTML received from the server before these responses are 

from the Web browser during an interactive sample session delivered to the browser. These translation functions are 

between the user of the client machine and tbe server 65 described below. 

application. In a typical interactive session, there may be As browser requests are received by the monitor 40, the 

15-20 URLs (although this number is merely representative) monitor performs the monitoring function or some other 
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function as selected by options specified when the monitor submitter routine(s), submits multiple instances of the ses- 

is started. As has been described, the monitor function writes sion to the e-business Web server. At step 60, the response 

the set of URLs (i.e. the URL trace) to the file 44. In addition time of the server and/or correctness of the responses 

to the Web requests, the monitor may also record informa- generated (using a response characterization written to the 

lion 48 (in the request file 44 or in some other file) 5 request file by the monitor) is then calculated or otherwise 

characterizing the response received from the server This determined. The response time may be determined by the 

characterization can be as simple as a checksum of the page monitor (by setting a "record timing data" option) directly or 

returned from the server, or a more elaborate characteriza- through other routines 

tion. Such characterization can then be later used to verify r , 

that the response received from the server is a correct in In ° ne em ^ d **nl, it may be desirable that multiple such 

response. Thus, for example, a verification might involve 10 recor^ng runs are done with the results mat a synthetic 

matching a checksum to fully parsing and analyzing the workload would then be manufactured out of the various 

HTML response. Any particular verification technique may P nor t0 supping the data to the 

be used HTTP submitter programs. 

As discussed above, each HTTP submitter routine 46 ^ a 4 illustrates a typical scenario for use of the monitor 

takes a list of URLs and associated data, connects to a Web m an end ^ measurement environment. The routine 

server, submits the URLs, and fetches the responses. This be S ins * ste P 62 ^ personnel or the like providing 

operation thus simulates the interactive session without acopy of the monitor to the end user. At step 64, the end user 

having to run the server application against an actual client starts the monitor in a "performance recording" mode on the 

machine. Such "submitter" routines are well known and 20 uscr>s cuCDt machine. At step 66, the user starts the Web 

within the state-of-the-art. They are available in the litera- browser and configures it to connect to the monitor (as will 

ture or via download on the Internet. In the present be described). The user then executes the e-business appti- 

invention, any suitable HTTP submitter routine 46 may be calion at ste P 68 * A test ^ men ^ at ste P 70 to determine 

used to perform the replay function provided the program whether the e-business interaction with the monitor has been 

can read the particular request file format created by the „ complete. If not, the routine cycles. If, however, the 

monitor 40 e-business transaction is complete, the routine continues at 

Another function thai may be provided by the monitor is s,e P 72 * terminate the e-business interaction with the 

to time the response time of the server and record this timing monitor At step 74, the monitor performance report is 

information for later analysis. Because measurements are analysis. 

completed by the monitor before the HTML response data is 30 Because the monitor and the browser preferably (but not 

returned to the browser for rendering, response time data necessarily) reside on the same physical machine or 

measured by the monitor is characteristic of the responses machines, third party attacks to observe the unencrypted 

returned to the user by the server (as opposed to being data between the browser and the monitor are more difficult, 

characteristic of the speed with which the browser executes of course, the request file will contain the user's userids and 

on the client machine). In addition, the monitor may identify 35 passwords or other private information (since it is necessary 

the component of time spent on the client machine perform- to record this in order to replay the session at a later date), 

ing the SSL protocol and it is thus able to remove that and thus, this file needs to be protected to avoid compro- 

component of time from the perceived response time at the mising the user's private data. In the system or performance 

SSL interface. Thus, the resulting response time statistics are test environment, the private information contained in the 

(as much as possible) a. true measure of the e-business 40 request file is test information only. In the end user 

response time as opposed to a measure of e-business environment, the file can be encrypted by the monitor using 

response time commingled with data relating to performance well-known methods. 

of the client machine. FIG. S is a flowchart illustrating a preferred routine for 
Any particular response time routines may be imple- irjitializing the monitor routine. The routine begins at step 76 
mented at the monitor. Exemplary response time monitoring 45 when the monitor is initiated. At step 78, the user specifies 
techniques are illustrated in U.S. Ser. Nos. 08/924,986 and to a "current Web server" the Internet address and port 
08/924,987, filed Sep. 8, 1997, and Sep. 8, 1997, number of the Web server application (e.g., 
respectively, titled "World Wide Web End User Response www.ebusiness.com:443) on which the application is sup- 
Time Monitor" and "World Wide Web Internet Delay Moni- ported. As will be seen, if (during the session) links are 
tor". Each such application is assigned to the assignee of this 50 followed to other servers, then the current Web server 
application and is incorporated herein by reference. address can change, which is discussed in detail below. The 
FIG. 3 is a flowchart illustrating a typical scenario for use routine then continues at step 80 with the user specifying 
of the monitor 40 in a performance or functional testing whether or not the monitor should use SSL and, if so, what 
environment. This scenario is merely representative. The cipher suite to use. As will be seen, the secure sockets (or 
routine begins at step 50 with the user (in this case, probably 55 °toer such secure) connection may be turned on and off 
a performance analyst or system test developer) starting the during execution of the e-business application as links to 
monitor and configuring it to sit between the user's browser otner servers are followed. At step 82, a test is done to 
and the associated e-business server under test At step 52, determine whether the user desires to write a request file (or, 
the user executes an e-business transaction against the perhaps, select the response time option). At step 84, a test 
server. At step 54, a test is done to determine if the session 60 ^ d° nc to determine whether the user desires to measure 
is complete. If not, the routine cycles and continues execut- performance statistics and to write a performance report file, 
ing the e-business transaction. If, however, the outcome of At step 86, the user identifies the port the monitor should 
the test at step 54 indicates that the session is complete, the listen at (for purposes of this example, it is assumed that the 
routine continues at step 56 and disconnects from the server. monitor listens at port 5000, although any suitable available 
During the session, the monitor generates the URL request 65 P ort mav 06 used). 

file as previously described. At step 58, the user takes the FIG. 6 is a flowchart illustrating a more detailed descrip- 

URL request file written by the monitor and, using the HTTP tion of the operation of the monitor. The routine begins at 
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step 87 when the monitor begins execution and indicates that meant by the "current web server" as well as "relative" and 

it is listening for connections on (for example) local machine "absolute" links on a Web page. According to the invention, 

port 5000. At step 88, the user starts the Web browser and a current_webserver is a state variable maintained by the 

connects tbe browser to the monitor. This is done by monitor. It is initialized to the name and port of the Web 

replacing the host name in the URL that starts the e-business 5 server specified at the monitor startup time (step 78 in FIG. 

interaction with the local host name and port that the monitor 5 ) It ^ up d a ted by the algorithm as discussed below, 

indicated it is listening to. For example, if the URL to initiate AU t ,. . .. . t . t . . __. . 

the e-business application is "https://www.ebusiiiess.com/ A "relative link means a hnkthat does not contain a ^Web 

logon" and the monitor indicated it is listening to port 500 ™ bosX na 1 me ' 0n most ™ b W& P*^ 1 ^ * ™ 

on the local host (with name localhost), then the following e-business web server, most of the links on the pages are 

URL: "http://localhost:5000/logon" would be used by the 10 relatively addressed. That is, they refer to other links on the 

user, same server. An "absolute" link means a link that includes 

It should be noted that, even though the server is config- a host namc - Such are tyP^y of toe form "http:// 

ured to use the https (or some other secure) protocol, the user www.newserver.com/newfile" or "https:// 

specifies an http (or any suitable protocol) connection to the www.newserver.com/newnle". In general, according to the 

monitor. This is necessary to keep tbe browser from encrypt- 15 invention, a relative link is sent to the current web server, 

ing the data before it is passed to the monitor. In particular, Absolute links require that the monitor change the current 

if the browser initiates a connection to https:// web server; the absolute link is thus converted to a relative 

localhost: 5000/logon, the browser would use the secure link and sent to the new current web server. This is the 

socket layer protocol and hence would try to encrypt data translation process referred to above, 

being sent to the monitor. As mentioned before, the monitor 20 relative links encountered in an HTML page do not 

establishes the https (or other secure) connection to the require translation before the HTML page is sent back to the 

actual server. From the standpoint of the browser then it browsef from me moniton ^ however, must be 

appears that the real server is at localhost: 5000 and that the - , „ . „. , 4 . » - < ' • _» r 

rr , . . « £ . translated to keep the browser from escaping: from the 

connection is an http connection instead of an https connec- ™ . : r , . , . , 

U r r monitor. Thus, it is desired to translate the absolute links into 

. u . j . 25 links that point back at the monitor. The monitor manufac- 

Once the browser is connected to the monitor, the routine « »_ • « * i i • i - 

continues at step 90 to test for HTTP requests. If the mres a ^stitute or fake hnk name and gives it to the 

outcome of the test at step 90 indicates that a request has ^ rowse [ ***** absolute J«* 1 Mmc - ^ "J*"*' 

been passed by the browser to localhost: 5000, the routine ^Pf the tru ^ hnk formation and follows the true hnk for 

continues at step 92 to translate the request (as described 30 , browscr * browscr latcr rcc i ucsts 0DC of ^ fakc 

below). Prior to translation, the URL is recorded. At step 94, unks * 

the translated request is then encrypted (if the secure pro- For example, if the server returns an HTML page con- 

tocol is being used) and, at step 96, then sent to the server taining a link of the form: "https://ww.newmachine.com/ 

indicated at the monitor startup time. A test is then done at newfile" and, if this is the first absolute link the monitor has 

step 98 to determine if a response to the request has been 35 encountered, the monitor translates this to a new link name, 

received. If not, the routine cycles and waits for the sav: "/momtorOOOOOl". It then records the first name in a list 

response. If the outcome of the test at step 98 indicates that called true_link_jiame»r and the second link in a list 

a response has been received, the routine continues at step called f ake_link_n ame* 1 " . This is repeated similarly for 

100 to decrypt the response (if the secure protocol is being me second absolute link the monitor encounters and so forth, 

used), perform the translation 102, and then return the 40 using names such as a /mom^or000002/' etc. This process is 

response to the browser for rendering at step 104. If desired, repeated for each absolute link that tbe monitor encounters, 

information about the response or comprising the response Using the routine described above with respect to FIG. 6, 

may be recorded at step 103. This completes the process. when a request is received from the browser, the URL being 

As discussed above, to maintain the "masquerade" that fetched is compared to the list of fake links. If a match is 

the monitor is the server, HTTP requests, as well HTTP and 45 found, then the monitor sets current_webserver to the host 

HTML responses, are "translated" so that absolute links name given in the corresponding true_link_name entry, 

within a particular request or response do not directly The monitor sets useSSL to true if the true _link_eDtry 

navigate the user between the page and the server (i.e. contains "https:" and to false if the true_link entry contains 

without passing first through the monitor). This translation is "http:". The monitor then opens the connection to the new 

necessary for several reasons. First, it is important that the 50 current_webserver (using SSL if appropriate) and sends a 

browser not see tbe real URL of the server. If it does, the user request for "/newfile" off to the new server. In the example 

could click on a link that points at the true server. At that above, if the browser requests "/monitorOOOOOl," then the 

point, the browser would fetch data directly to the server, monitor will instead establish an SSL connection to host 

bypassing the monitor. In essence, the browser has www.newmachine.com, and ask for the file "/newfile" from 

"escaped" from the monitor. This is undesirable. Second, it 55 that host, using the HTTP method and other data supplied to 

is required that the browser continues to use an http (or other it by the browser. The current_webserver will become 

like) protocol between itself and the monitor. Otherwise, the www.newmachine.com. 

data that the monitor wishes to record (when writing the Request and response translation is also required in the 

request file) will be encrypted and, hence, uninteUigible to case of HTTP redirect responses. If the server issues a 

the monitor. Moreover, if the browser follows a link to 60 redirect response, the HTTP header contains a new location 

another server, the monitor must intercept that link, replac- for the browser to fetch. If this location includes a host 

ing it with a substitute or so-called "fake" link that leads name, the browser will fetch it directly, once again allowing 

back to the monitor. If the browser follows the fake link, the the browser to "escape" from the monitor. This problem is 

monitor translates it to the true destination, and makes the solved by watching for redirect responses, capturing the 

correct connection for the browser. 55 redirect host name and using that name to update the current 

To explain the monitor's algorithms for request and webserver name. The redirect name is then translated into 

response translation, it is first desirable to define what is the monitor's name and the response is returned to the 
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browser. This keeps the browser "captured" in that it still host and port name where the monitor is currently 

asks the monitor for the next request in spite of the host- listening for connections in the internal state variable 

to-host redirect that occurred. And, if the next request is a "current__hosUame'\ It then replaces all occurrences 

relative request, the monitor will have been redirected to the of real__host_name in the redirect response with 

correct host. 5 current_host_name. 

The request and response translation algorithm can now b. It sets current_webserver to the real host name. Thus 

be described in detail. The following internal state variables any new relative links will be resolved with respect to 

govern the translations that the monitor makes: me new host name. 

1. current_webserver: the current webserver name and U ma ? 1x5 required to keep the true_link_name and 
p OIt 10 fake_link__name table for each individual web page, since 

2. have_host_translation: initialized to false. This van- a I* t ^ mech ? nisnl * recall an old page 
able tells the monitor whether or not it has seen the real_ °° » \ ^T^L ™ 
host_name and thus, whether or not it has a translation from t Alth ° u » h ^ ., momtor 15 desc "^ above « » 

the current_host_name (the monitor's host and port *™*er, » similar program could be coveted usmg the 

. v tn t . . „ t „ \r M , , . . IS H1TP proxy protocol and the monitor could be constructed 

number) to the host name of the real server (real_host_ f™ r ~, ^ - A , A . JL . . , 

„ nma \ as an HTTP proxy. The nature of the translations would 

name). . . T • * ■ » *.* . 

„ ' . . . ...... m . change, however. In particular, one would still have to 

3. have url_translations: initialized to false. This van- tnB ^ Iinks retumed tQ the browser tQ k me browser 

able tells the monitor whether or not it has a list of url from encountering https: ^ for it t0 follow . af the 

translations to apply to the request. have_url_translations is 2Q browser encounters an https: ^ it ^ ^ 1 t0 

set to j true when a previous request sent back to the browser an SSL ^ ^ mon itor.) The problems of 

included an absolute hnk name/Ine monitor keeps a unique havifl the browser „ frQm ^ monilor WQuld QQi 

translanon for each such link. These translauons are kept in occur in t^ proxy version of me monitor since the browser 

an array: true _link_names- \ The names that these links would be configured to send all requests to the monitor, 

were translated to by the monitor are kept m a second array: ^ ThuSj the teachings of ^ mvent i on would apply to ^ 

fake JinUamc* . The number of such entries is kept in implementation as well with the following difference. If the 

number_of_hnk_translations. monitor fa bssMjBd in ^ cnd ^ environment, then all 

4. useSSL: initialized to the value specified by the com- requests issued by the user's browser would be routed to the 
mand line either true (use SSL) or false (do not use SSL). monitor, regardless of whether or not the request was for the 
useSSL indicates whether or not the monitor should use SSL 30 server being monitored. 

in communicating with the current webserver. It is updated The present invention provides numerous advantages 

when the current webserver changes. over tn e prior art. When using the monitor, one merely uses 

The following translations are performed on a request that the actual Web pages that are desired to be evaluated when 

the monitor receives from the browser before the request is testing the e-business application. The monitor writes the 

sent to the server 35 request file, and then that file may be used with a set of 

1. If have_host_translation is true, change each occur- HTTP submitter routines to create a benchmark for the 
rence of current_host_name (the monitor's name) to real_ application. The inventive solution is thus easy to install and 
host_name (the web server's name). This handles such maintain. It does not depend on display layout or browser 
things as the HTTP header entry "Host:" and the HTTP configuration; indeed, the monitor is independent of the 
header entry "Re ferrer:". If have_host_translau*on is false, 40 browser. 

do nothing in this step. Because the monitor does not render the Web page, times 

2. If have_url_translations is true, then the URL being consumed on the client to do such rendering or other 
fetched is compared against the table of fake_link_name. If browser specific functions are not included in the response 
the URL is found in the fake_Jink_name list, then the times measured by the monitor. Hence the response time 
monitor does the following: 45 numbers more correctly measure server response time and 

a. The current_webserver is updated to the webserver arc lcss influenced bv ^ s P ecd of clicnt machine, 
name found in the corresponding real_Jink_name This mvenUon thus o^scribes a method of capturing a test 
en try workload that has the following characteristics: it functions 

u eoT ... c i j j- . . for Web requests both for http and https (secure sockets) 

b. useSSL is set to true or false depending on whether or „ . i • i_i j . • * « j 

♦ «u — i r i . * * «i_„ » 50 protocols, it is portable and easy to install and use, and it can 

not the real_link_name entry contains "https: or f , , u K 3 Ti ' . . 

"httrv" be used with any Web browser or server. It provides a simple 

. „ wa Y to generate benchmarks or functional test suites appro- 

c. The fake — link — name is replaced by the file name (the priate for measuring the performance of or testing of 
portion of the url after the host name) from the real_ e-business as well as other server applications. In addition, 
hnk_name entry. 55 me metnoc i described can be used in the end user environ- 

d. the monitor initiates a connection and fetches the file m ent to provide accurate measurement of the end-to-end 
from the new current_webserver, using SSL if useSSL response time encountered by the user as the user interacts 
15 ^ ruc * with the e-business application. 

The following are the translations that the monitor per- The inventive tool described by this invention preferably 

forms on a response that the monitor receives from the host so only inspects those URLs requested from the server being 

before it returns the request to the browser: monitored; other URLs are preferably not even delivered to 

1. If the response is a redirect response, and if the the tool From an end user perspective, this can be an 

Location: field of the http header includes a host name (even important privacy advantage. 

if the host name is that of the current host), then the monitor One of the preferred implementations of the monitor (and 

does the following: 65 associated routines) of the present invention is as a set of 

a. It records the host name from the Location Field in the instructions (program code) in a code module resident in the 

internal state variable "real_host__name". It places the random access memory of the computer, preferably the 
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client computer. Until required by the computer, the set of 
instructions may be stored in another computer memory, for 
example, in a hard disk drive, or in a removable memory 
such as an optical disk (for eventual use in a CD ROM) or 
floppy disk (for eventual use in a floppy disk drive), or 
downloaded via the Internet or other computer network. 

In addition, although the various methods described are 
conveniently implemented in a general purpose computer 
selectively activated or reconfigured by software, one of 
ordinary skill in the art would also recognize that such 
methods may be carried out in hardware, in firmware, or in 
more specialized apparatus constructed to perform the 
required method steps. 

As used herein, "Web client" should be broadly construed 
to mean any computer or component thereof directly or 
indirectly connected or connectable in any known or later- 
developed manner to a computer network, such as the 
Internet. The term "Web server" should also be broadly 
construed to mean a computer, computer platform, an 
adjunct to a computer or platform, or any component 
thereof. Of course, a "client" should be broadly construed to 
mean one who requests or gets the file, and "server" is the 
entity which downloads the file. 

Moreover, the invention may be used or practiced in any 
type of Internet Protocol (IP) client, not just within an 
HTTP-complaint client having a Web browser. Thus, as used 
herein, references to "browser" should be broadly construed 
to cover an IP client. 

Having thus described my invention, what I claim as new 
and desire to secure by letters patent is set forth in the 
following claims. 

What is claimed is: 

1. A method of generating a trace of requests to a given 
server application in a computer network during a transac- 
tion session initiated from a client having a Web browser, 
comprising: 

connecting the Web browser to a monitoring process for 
generating the trace; 

during the transaction session, intercepting each HTTP 
request intended for the given server application and 
redirecting the HTTP request to the monitoring pro- 
cess; 

recording the HTTP request in the trace; 

issuing a given request from the monitoring process to the 
application server; 

delivering a response to the given request from the 
application server to the monitoring process; 

if the response to the given request includes an absolute 
URL that that has not been encountered by the moni- 
toring process, translating the absolute URL into a 
modified URL; and 

returning the response with the modified URL back to the 
Web browser such that, when the Web browser attempts 
to retrieve the modified URL, a new HTTP request is 
passed through the monitoring process and recorded in 
the trace instead of being used to fetch a resource from 
the application server directly. 

2. The method as described in claim 1 wherein the 
monitoring process runs on the client machine. 

3. The method as described in claim 1 wherein a connec- 
tion between the Web browser and the monitoring process is 
not secure. 

4. The method as described in claim 3 wherein a connec- 
tion between the monitoring process and the application 
server is secure. 

5. The method as described in claim 1 wherein the server 
application is an e-business application. 
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6. The method as described in claim 1 wherein the 
computer network is a network selected from the group of 
networks consisting of an intranet, an extranet and the 
Internet's World Wide Web. 
5 7. A method of evaluating performance of a given server 
application in a computer network environment, comprising 
the steps of: 

connecting a Web browser of a client machine to a 

monitoring process for generating a trace; 
10 during a simulated transaction session, forcing any HTTP 

request intended for the given server application to be 

redirected to the monitoring process; 
recording each HTTP request in the trace; and 
replaying the trace to gather information to evaluate the 

performance of the given server application. 

8. The method as described in claim 7 wherein the 
monitoring process runs on the client machine. 

9. The method as described in claim 8 wherein a connec- 
2o tion between the Web browser and the monitoring process is 

unencrypted. 

10. The method as described in claim 9 wherein a 
connection between the monitoring process and the appli- 
cation server is secure. 

11 . The method as described in claim 7 wherein the server 
application is an e-business application. 

12. The method as described in claim 11 wherein the 
computer network is a network selected from the group of 
computer networks consisting of an intranet, an extranet and 

5Q the Internet's World Wide Web. 

13. The method as described in claim 7 wherein the step 
of replaying the trace comprises: 

having each of a set of HTTP submitter routines execute 
the trace against the server application. 
3S 14. The method as described in claim 13 wherein each of 
the set of HTTP submitter routines simulates a user of a 
client machine. 

15. A computer program product in a computer-readable 
medium for generating a trace of requests to a given server 
w application in a computer network during a transaction 
session initiated from a client machine having a Web 
browser, the program product comprising: 

means supported on the client machine for intercepting 
any HTTP request issued from the Web browser and 
l5 intended for the given server application; 

means responsive to the intercepting means for recording 
information associated with the HTTP request to gen- 
erate the trace; and 
a set of HTTP processes each of which simulate a live 
50 user, wherein each HTTP process replays the trace 
against the given server application; and 
means for evaluating data generated by the HTTP pro- 
cesses to determine a performance of the given server 
application against the simulated live users. 
55 16. The computer program product as described in claim 

15 wherein the information associated with the HTTP 
request includes a URL. 

17. The computer program product as described in claim 

16 wherein the trace comprises a set of URLs and a set of 
60 associated responses. 

18. The computer program product as described in claim 

17 wherein the server application is an e-business applica- 
tion. 

19. The computer program product as described in claim 
65 18 wherein the forcing means includes means for forcing the 

Web browser to issue the HTTP requests to a given port 
associated with the client machine. 



02/03/2004, EAST Version: 1.4.1 



US 6,286,046 Bl 



13 



14 



20. A computer program product in a computer-readable 
medium for performance evaluation of a given server appli- 
cation in a computer network environment, comprising: 

means supported on the client machine for intercepting 
any HTTP request issued from the Web browser and 
intended for the given server application; 

means responsive to the intercepting means for recording 
information associated with the HTTP request to gen- 
erate a session trace; 

a set of HTTP submitter routines each of which execute 
the trace against the server application; and 

means for measuring performance of the server applica- 
tion as the trace is executed by the HTTP submitter 
routines. 

21. The computer program product as described in claim 
20 wherein the information associated with the HTTP 
request includes a URL. 

22. A computer connectable to a given server application 
in a computer network environment, comprising: 

a processor; 

an operating system; 

a Web browser; 

means for intercepting any HTTP request issued from the 
Web browser and intended for the given server appli- 
cation; 

means responsive to the intercepting means for recording 
information associated with the HTTP request to gen- 
erate a session trace; 

a set of HTTP submitter routines each of which execute 
the trace against the server application; and 

means for measuring performance of the server applica- 
tion as the trace is executed by the HTTP submitter 
routines. 

23. An e-business transaction session monitor for gener- 
ating a trace of URL requests to a given e-business server 
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application in a computer network during an e-business 
transaction session initiated from a client having a Web 
browser, comprising: 

code for forcing an HTTP request issued from the Web 
browser and intended for the given e-business server 
application to be redirected through the monitor, 
wherein the code includes code for rewriting absolute 
URLs into modified URLs to ensure that the Web 
browser does not escape from the monitor during the 
transaction session; and 
code responsive to the forcing code for recording URLs 
associated with the HTTP requests to generate a trace. 

24. The e-business transaction monitor as described in 
15 claim 23 further including means for replaying the trace. 

25. The e-business transaction monitor as described in 
claim 24 wherein the means for replaying comprises: 

a set of HTTP submitter routines each of which execute 
the trace concurrently against the server application; 
and 

means for measuring performance of the server applica- 
tion as the trace is executed concurrently by the HTTP 
submitter routines. 

26. The e-business transaction monitor as described in 
claim 23 wherein the e-business server application is an 
Internet banking transaction. 

27. The e-business transaction monitor as described in 
claim 23 wherein the e-business server application is an 
Internet sales transaction. 

28. The e-business transaction monitor as described in 
claim 23 wherein the e-business server application is an 
Internet supply transaction. 

29. The e-business transaction monitor as described in 
claim 23 wherein the e-business server application is an 
Internet service transaction. 
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